Yes. For whatever reason, although the Rational instance for FromJSON accepts both number and object style, the ToJSON instance never produces numbers, only object style:

instance (ToJSON a, Integral a) => ToJSON (Ratio a) where
    toJSON r = object [ "numerator"   .= numerator   r
                      , "denominator" .= denominator r
                      ]
    {-# INLINE toJSON #-}

    toEncoding r = E.pairs $
        "numerator" .= numerator r <>
        "denominator" .= denominator r
    {-# INLINE toEncoding #-}

So we do need this toRationalJSON workaround.

Perhaps that is worth proposing upstream as a PR to do the above trick for the instance provided by the library.

And also:

λ> encode (1 :: Rational)
"{\"numerator\":1,\"denominator\":1}"

Until and if such change gets merged upstream, I'd also suggest importing toRationalJSON from Cardano.Api.Orphans instead of redefining another copy again here.

I hesitate mainly because I can't use it unless I export it from Cardano.Api anyway, in which case it becomes part of our API which I don't want especially because we want to push it upstream in a way that doesn't need an extra function.

I did not realize Cardano.Api.Orphans is an exposed module. That is a very strange thing to do considering that anyone who imports Cardano.Api will get all those orphan instances into scope anyways (all instances are imported through modules transitively). I would suggest moving that module into other-modules in the cabal file

Actually, my mistake. I thought I was using toRationalJSON from outside cardano-api, but I don't. But it still is a bit strange to export functions from a module that called Orphans. Not a hard objection though.

I will move it to a new module Cardano.Api.Json. Seems the cleanest.